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Abstract 


This document defines IS-IS extensions to support multicast 
forwarding using the Bit Index Explicit Replication (BIER) 


architecture. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
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1. Introduction 


Bit Index Explicit Replication (BIER) [RFC8279] defines an 
architecture where all intended multicast receivers are encoded as a 
bitmask in the multicast packet header within different 
encapsulations such as described in [RFC8296]. A router that 
receives such a packet will forward the packet based on the bit 
position in the packet header towards the receiver(s) following a 
precomputed tree for each of the bits in the packet. Each receiver 
is represented by a unique bit in the bitmask. 


This document presents necessary extensions to the currently deployed 
IS-IS for IP [RFC1195] to support distribution of information 
necessary for operation of BIER domains and subdomains. This 
document defines a new TLV to be advertised by every router 
participating in BIER signaling. 


This document defines support for MPLS encapsulation as specified in 


[RFC8296]. Support for other encapsulation types and the use of 
multiple encapsulation types are outside the scope of this document. 


Ginsberg, et al. Standards Track [Page 2] 


RFC 8401 BIER Support via IS-IS June 2018 


2s 


Terminology 


Some of the terminology specified in [RFC8279] is replicated here and 
extended by necessary definitions: 


BIER: Bit Index Explicit Replication. The overall architecture of 
forwarding multicast using a bit position. 


BIER-OL: BIER Overlay Signaling. The method for the BFIR to learn 
about BFERs. 


BFR: Bit Forwarding Router. A router that participates in Bit Index 
Multipoint Forwarding. A BFR is identified by a unique BFR-prefix 
in a BIER domain. 


BFIR: Bit Forwarding Ingress Router. The ingress border router that 
inserts the BitString into the packet. Each BFIR must have a 
valid BFR-id assigned. 


BFER: Bit Forwarding Egress Router. A router that participates in 
Bit Index Forwarding as a leaf. Each BFER must be a BFR. Each 
BFER must have a valid BFR-id assigned. 


BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 
BIER subdomain: A further distinction within a BIER domain 
identified by its unique subdomain identifier. A BIER subdomain 


can support multiple BitString Lengths. 


BFR-id: An optional, unique identifier for a BFR within a BIER 
subdomain. 


Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved 
for this purpose. 


BAR: BIER Algorithm. Used to calculate underlay next hops. 


IPA: IGP Algorithm. May be used to modify, enhance, or replace the 
calculation of underlay paths as defined by the BAR value. 


SPF: Shortest Path First routing calculation based on the IGP link 
metric. 
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2.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. IANA Considerations 


This document adds the following entry to the "Sub-TLVs for TLVs 135, 
235, 236, and 237" registry. 


Value: 32 
Name: BIER Info 
This document also introduces a new registry for sub-sub-TLVs for the 
BIER Info sub-TLV. The registration policy is Expert Review as 
defined in [RFC8126]. The "Sub-sub-TLVs for BIER Info Sub-TLV" has 
been created within the "IS-IS TLV Codepoints" registry. The defined 
value is as follows: 
Type Name 
1 BIER MPLS Encapsulation 
IANA has created the "BIER Algorithms" registry within the "Bit Index 
Explicit Replication (BIER)" registry. The registration policies 
[RFC8126] for this registry are: 
"Standards Action" for values 0-127 
"Specification Required" for values 128-239 
"Experimental Use" for values 240-254 
The initial values in the "BIER Algorithms" registry are: 


0: No BIER-specific algorithm is used 


255: Reserved 
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4. Concepts 


4.1. BIER Domains and Subdomains 


An IS-IS-signaled BIER domain is aligned with the scope of 
distribution of BFR-prefixes that identify the BFRs within IS-IS. In 
such a case, IS-IS acts as the supporting BIER underlay. 


Within such a domain, the extensions defined in this document 
advertise BIER information for one or more BIER subdomains. Each 
subdomain is uniquely identified by a subdomain-id (SD). Each 
subdomain is associated with a single IS-IS topology (MT) [RFC5120], 
which may be any of the topologies supported by IS-IS. Local 
configuration controls which <MT,SD> pairs are supported by a router. 
The mapping of subdomains to topologies MUST be consistent within the 
IS-IS flooding domain used to advertise BIER information. 


Each BIER subdomain has as its unique attributes the encapsulation 
used and the type of tree it uses to forward BIER frames (currently 
always SPF). Additionally, per supported BitString length in the 
subdomain, each router will advertise the necessary label ranges to 
support it. 


4.2. Advertising BIER Information 


BIER information advertisements are associated with a new sub-TLV in 
the extended reachability TLVs. BIER information is always 
associated with a host prefix, which MUST be a node address for the 
advertising node. If this is not the case, the advertisement MUST be 
ignored. Therefore, the following restrictions apply: 


o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 
prefix. 


o When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the 
N flag MUST be set and the R flag MUST NOT be set. 


o BIER sub-TLVs MUST be included when a prefix reachability 
advertisement is leaked between levels. 


5. Procedures 

5.1. Multi-Topology and Subdomain 
A given subdomain is supported within one and only one topology. All 
routers in the flooding scope of the BIER sub-TLVs MUST advertise the 


same subdomain within the same multi-topology. A router receiving an 
<MT,SD> advertisement that does not match the locally configured pair 
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MUST report a misconfiguration of the received <MT,SD> pair. All 
received BIER advertisements associated with the conflicting <MT,SD> 
pair MUST be ignored. Note that in the presence of such a 
misconfiguration, this will lead to partitioning of the subdomain. 


Example: 


The following combination of advertisements are valid: <0,0> <0,1>, 
and <2,2>. 


The following combination of advertisements are invalid: <0,0> <0,1>, 
and <2,0>. Advertisements associated with <0,0> and <2,0> must be 
ignored. 


5.2. BFR-id Advertisements 


If a BFER/BFIR is configured with a BFR-id, then it advertises this 
value in its BIER advertisements. If no BFR-id is configured, then 
the value "Invalid BFR-id" is advertised. A valid BFR-id MUST be 
unique within the flooding scope of the BIER advertisements. All 
BFERS/BFIRs MUST detect advertisement of duplicate valid BFR-IDs for 
a given <MT,SD>. When such duplication is detected, all of the 
routers advertising duplicates MUST be treated as if they did not 
advertise a valid BFR-id. This implies they cannot act as BFER or 
BFIR in that <MT,SD>. 


5.3. Logging Misconfiguration 


Whenever an advertisement is received that violates any of the 
constraints defined in this document, the receiving router MUST 
support logging this occurrence. Logging SHOULD be dampened to avoid 
excessive output. 


5.4. Flooding Reduction 


It is expected that changes in the BIER domain information that is 
advertised by IS-IS occur infrequently. If this expectation is not 
met for an extended period of time (more than a few seconds of 
burstiness), changes will increase the number of Link State PDU (LSP) 
updates and negatively impact performance in the network. 
Implementations SHOULD protect against this possibility by, for 


example, dampening updates if they occur over an extended period of 
time. 


Ginsberg, et al. Standards Track [Page 6] 


RFC 8401 BIER Support via IS-IS June 2018 


6. Packet Formats 


All IS-IS BIER information is carried within the TLVs 235, 237, 
[RFC5120], 135 [RFC5305], or 236 [RFC5308]. 


6.1. BIER Info Sub-TLV 


This sub-TLV carries the information for the BIER subdomains that the 
router participates in as a BFR. This sub-TLV MAY appear multiple 
times in a given prefix-reachability TLV -- once for each subdomain 
supported in the associated topology. 


The sub-TLV advertises a single <MT,SD> combination followed by 
optional sub-sub-TLVs as described in the following sections. 


0 1 2 3 
01 2. 34 56789 01.23.45 67 8 9 O01 2°34 5.6 7°38 9 OL 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| BAR | IPA | subdomain-id | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| BFR-id | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| sub-sub-TLVs (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H+HHH HHHMH MHH 


Type: As indicated in the IANA section. 

Length: Variable 

BAR: BIER Algorithm. Specifies a BIER-specific algorithm used to 
calculate underlay paths to reach BFERs. Values are allocated 
from the "BIER Algorithms" registry. 1 octet. 

IPA: IGP Algorithm. Specifies an IGP Algorithm to either modify, 
enhance, or replace the calculation of underlay paths to reach 
BFERs as defined by the BAR value. Values are from the IGP 
Algorithm registry. 1 octet. 


subdomain-id: Unique value identifying the BIER subdomain. 1 octet. 


BFR-id: A 2-octet field encoding the BFR-id, as documented in 


[RFC8279]. If no BFR-id has been assigned, the value of this 
field is set to "Invalid BFR-id", which is defined as illegal in 
[RFC8279]. 
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The use of non-zero values in either the BAR field or the IPA field 
is outside the scope of this document. If an implementation does not 
support the use of non-zero values in these fields but receives a 
BIER Info sub-TLV containing non-zero values in these fields, it 
SHOULD treat the advertising router as incapable of supporting BIER 
(one way of handling incapable routers is documented in Section 6.9 
of [RFC8279] and additional methods may be defined in the future). 


6.2. BIER MPLS Encapsulation Sub-sub-TLV 


This sub-sub-TLV carries the information for the BIER MPLS 
encapsulation including the label range for a specific BitString 
length for a certain <MT,SD>. It is advertised within the BIER Info 
sub-TLV (Section 6.1). This sub-sub-TLV MAY appear multiple times 
within a single BIER Info sub-TLV. 


If the same BitString length is repeated in multiple sub-sub-TLVs 
inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be 
ignored. 


Label ranges within all BIER MPLS Encapsulation sub-sub-TLVs across 
all BIER Info sub-TLVs advertised by the same BFR MUST NOT overlap. 
If overlap is detected, the advertising router MUST be treated as if 
it did not advertise any BIER sub-TLVs. 


Label values MUST NOT match any of the reserved values defined in 
[RFC3032]. 


0 1 2 3 
0 123 45 6 7°38 9-0 1 2 3-4-5-6 7 8 9-0 1-23-45 6 7.8 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Max SI |BS Len | Label 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type: Value of 1 indicating MPLS encapsulation. 
Length: 4 


Max SI: Maximum Set Identifier (Section 1 of [RFC8279]) used in the 
encapsulation for this BIER subdomain for this BitString length, 1 
octet. Each SI maps to a single label in the label range. The 
first label is for SI=0, the second label is for SI=1, etc. If 
the label associated with the Maximum Set Identifier exceeds the 
20-bit range, the sub-sub-TLV MUST be ignored. 
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Local BitString Length (BS Len): Encoded BitString length as per 
[RFC8296]. 4 bits. 


Label: First label of the range, 20 bits. The labels are as defined 
in [RFC8296]. 


7. Security Considerations 
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 


The Security Considerations section of [RFC8279] discusses the 
possibility of performing a Denial-of-Service (DoS) attack by setting 
too many bits in the BitString of a BIER-encapsulated packet. 
However, this sort of DoS attack cannot be initiated by modifying the 
IS-IS BIER advertisements specified in this document. A BFIR decides 
which systems are to receive a BIER-encapsulated packet. In making 
this decision, it is not influenced by the IS-IS control messages. 
When creating the encapsulation, the BFIR sets one bit in the 
encapsulation for each destination system. The information in the 
IS-IS BIER advertisements is used to construct the forwarding tables 
that map each bit in the encapsulation into a set of next hops for 
the host that is identified by that bit, but it is not used by the 
BFIR to decide which bits to set. Hence, an attack on the IS-IS 
control plane cannot be used to cause this sort of DoS attack. 


While a BIER-encapsulated packet is traversing the network, a BFR 
that receives a BIER-encapsulated packet with n bits set in its 
BitString may have to replicate the packet and forward multiple 
copies. However, a given bit will only be set in one copy of the 
packet. This means that each transmitted replica of a received 
packet has fewer bits set (i.e., is targeted to fewer destinations) 
than the received packet. This is an essential property of the BIER- 
forwarding process as defined in [RFC8279]. While a failure of this 
process might cause a DoS attack (as discussed in the Security 
Considerations of [RFC8279]), such a failure cannot be caused by an 
attack on the IS-IS control plane. 


Further discussion of BIER-specific security considerations can be 
found in [RFC8279]. 
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